Summary

Fixes the /sso-grant 404 introduced by PR #1309 for anonymous visitors,
without forcing them through wp-login.php.

PR #1309 changed handle_broker()'s JSONP probe response from
{code: 0, message: 'Broker not attached'} (which triggered wu.sso_denied()
on the client and set the wu_sso_denied cookie) to
{verify: 'must-redirect', server: <main_url>} (which top-level navigates
to <main>/sso-grant?broker=...&token=...&checksum=...&return_url=<broker>).

That fix resolved a real bug — logged-in main-site users were getting
falsely denied on first hit — but it introduced a regression for
anonymous visitors on broker subsites:

1. Anonymous visitor lands on a broker subsite (e.g. a free-checkout
   page, a landing page, a marketing page).
2. sso.js runs the JSONP probe → main site responds must-redirect.
3. Browser top-navigates to <main>/sso-grant?....
4. handle_server() runs on the main site with no logged-in user and
   response_type = redirect — the not-logged-in non-JSONP branch.
5. That branch fell through with the comment
   // Just let WordPress show the login page - don't exit, but
   /sso-grant is not wp-login.php, so WordPress rendered its
   404 template and Sidekick/page caches subsequently cached it,
   leaving the cross-domain SSO entry permanently broken for new
   anonymous visitors. Observed in production on the
   sdaiagent.com free-checkout flow today.

What this PR does

When handle_server() runs on /sso-grant for a not-logged-in user,
redirect back to the broker's /sso URL with sso_verify=invalid
appended.

This re-uses the existing denial-signalling pattern already implemented
in handle_broker() (the 'invalid' === $verify_code branch a few
hundred lines below): on receiving the signal, handle_broker() sets
wu_sso_denied=1 on the broker domain for 5 minutes and redirects to
the original return_url. sso.js (assets/js/sso.js:22) then sees
the cookie and skips the JSONP probe so the user browses anonymously
without further SSO disruption.

If the broker URL is missing (malformed grant request) we exit silently
rather than 404 or force login.

Why not redirect to wp-login.php?

An earlier revision of this PR redirected anonymous visitors to
wp_login_url($return_url). That was wrong for the same reason
falling through to the 404 template was wrong: the broker page the
visitor came from may be intentionally anonymous — free-checkout,
landing pages, public marketing pages. Forcing those visitors through
the WordPress login screen breaks the conversion flow they were on.

The denial-signal mechanism mirrors the explicit "anonymous, do
nothing" contract that existed before PR #1309 and re-uses the
infrastructure (wu_sso_denied cookie, sso.js skip path) that's
already in place. No new client-side code, no new cookie, no new
contract.

Regression test

tests/WP_Ultimo/SSO/SSO_Test.php —
test_handle_server_source_signals_denial_when_not_logged_in_non_jsonp()

Source-pattern test (matching the convention already used in this
file because handle_server() calls exit) that asserts:

1. The not-logged-in non-JSONP branch appends sso_verify=invalid to
   the broker URL via add_query_arg().
2. The branch calls wp_safe_redirect($denial_url, 302, 'WP-Ultimo-SSO'); exit;.
3. The branch does not call wp_safe_redirect(wp_login_url(...))
   (explicit guard catching the rejected earlier approach).
4. The stale pre-fix(sso): return verify: must-redirect from unattached JSONP probe #1309 comment is gone.

Verification

Local dev (mygratis.site on the dev FrankenPHP instance, with this
branch checked out):

$ curl -sk -D - -o /dev/null \
    "https://mygratis.site/sso-grant?broker=TESTPROBE&token=test&checksum=test&return_url=https%3A%2F%2Ftesttenant.mygratis.site%2Fsso" \
    | grep -i -E "(HTTP|location|cache)"
HTTP/2 302
cache-control: no-cache, must-revalidate, max-age=0, no-store, private
location: https://testtenant.mygratis.site/sso?sso_verify=invalid
pragma: no-cache
x-ultimo-cache: prevent-caching

Pre-fix this returned HTTP 200 with the WordPress 404 template
(later cached as x-sidekick-cache: HIT on subsequent requests).

Test suite

$ vendor/bin/phpunit --filter test_handle_server_source_signals_denial \
    tests/WP_Ultimo/SSO/SSO_Test.php --no-coverage
OK (1 test, 6 assertions)

$ vendor/bin/phpunit --filter SSO_Test tests/WP_Ultimo/SSO/SSO_Test.php
OK (62 tests, 96 assertions)

$ vendor/bin/phpstan analyse inc/sso/class-sso.php --memory-limit=1G
[OK] No errors

$ vendor/bin/phpcs inc/sso/class-sso.php
(no new violations introduced)

Notes for reviewers

• The cross-domain wp_safe_redirect() from the main site to a broker
  domain is permitted via the allow_network_redirect_hosts filter
  registered in inc/class-domain-mapping.php:61. Same mechanism
  handle_broker() already relies on for the existing sso_verify=invalid
  branch.
• Pre-existing UM behaviour: wu_request() runs values through
  sanitize_text_field(), which strips %XX sequences. A nested
  return_url inside the broker URL will therefore lose its percent
  encoding. In practice the broker host stays intact (which is what
  matters for the denial cookie), and wp_safe_redirect() in
  handle_broker() falls back to home_url() for malformed
  return_url values. Fixing the broader URL-sanitisation behaviour
  is out of scope for this regression fix.

Refs #1309

aidevops.sh v3.20.5 plugin for OpenCode v1.15.12 with claude-opus-4-7 spent 1d 14h and 767,081 tokens on this with the user in an interactive session.